I'm testing this, but I noticed some issues:

• you can't scroll to the end quickly, if you want to go somewhere bellow the first page you have to keep scrolling manually until things are loaded (and if you just grab the scrollbar and hold it at the bottom of the scroll track, the loading of other elements doesn't work because the scroll events may not trigger as expected), check this video

• I think it's currently broken on the latest release, but with this change the feature of go back from the game to the library and preserve the scroll position (so you end up around the same place you were before) will never work

• I just reported this issue that happens in the main branch [UX] When a game finishes installing, sometimes you are taken to the top of the library page #2456, but it's even more noticeable with the pagination, because you are taken back to the top with only the first page loaded, so you have to start scrolling down again from the top loading pages to get to wherever you were before

I understand the reason to do bottom-scroll pagination, but at least for me it feels slower now that I see things loading as I scroll and that I can't freely scroll.

Yes, noticed these things as well. But we need to think how can we manage to deal with huge libraries if we do not implement pagination.

Because the way it is right now if someone has a big library, I think 1000 games or more, Heroic is pretty laggy since it loads all the game cards, images, gameInfo, etc. in the memory. So we have some people that said that Heroic takes up to 2 minutes to load with a library of over 2000 games.

Even if we find another way to paginate that, scrolling to the end will always be impossible. One solution though is just to click on the A-Z icon, since it will invert the list and you will see the end of it first.

on my other PR I changed the HardDrive icon to show only installed games, so this also will make the list small when not installing any new game.

I think that the tradeoffs here are clear and I prefer pagination with faster loading time and less memory usage over being able to navigate to the end of the list fast, since we can already do that by using the AZ button.

Yes, noticed these things as well. But we need to think how can we manage to deal with huge libraries if we do not implement pagination.

Because the way it is right now if someone has a big library, I think 1000 games or more, Heroic is pretty laggy since it loads all the game cards, images, gameInfo, etc. in the memory. So we have some people that said that Heroic takes up to 2 minutes to load with a library of over 2000 games.

Even if we find another way to paginate that, scrolling to the end will always be impossible. One solution though is just to click on the A-Z icon, since it will invert the list and you will see the end of it first.

on my other PR I changed the HardDrive icon to show only installed games, so this also will make the list small when not installing any new game.

I think that the tradeoffs here are clear and I prefer pagination with faster loading time and less memory usage over being able to navigate to the end of the list fast, since we can already do that by using the AZ button.

I'll try to do some profiling to try to understand what's actually slow, because for images we could do something like don't load the image until it's inside the viewport (but still show the game card so it fills the space and you can scroll freely for example), but I also want to understand if there's something else happening that is slowing things down (like, I've noticed that fetching gog images information is pretty slow, and it does that for the whole library, we could defer those requests to speed the gog library load), but I also understand the game card component does too much maybe?

I think a progress indication of what's happening also helps with the perceived speed, if it's just a spinner it feels like it might be stuck, but if we report updates like Loading GOG games... Fetching cover art (10/200) Fetching cover art (50/200) etc the user would know what's happening (and I think it can also help us understand where is the time going (a user could say hey, it takes super long in this specific step)

thinking about that report of the library taking 2 minutes to load, do we know when is that time spent? because if it's in the backend when it's refreshing the libraries, using pagination won't fix that though, since we'll still need to process the whole library (it's not that we process the library in pages)

because I suspect it's the issue I've noticed with the GOG library, it needs to do extra http requests to fetch the cover art information and that seems to be the slowest part of the library refresh

@arielj

I'll try to do some profiling to try to understand what's actually slow, because for images we could do something like don't load the image until it's inside the viewport (but still show the game card so it fills the space and you can scroll freely for example),

We did that already we added the lazy property to the cachedImage component. Although this also came with another issue. Sometimes the game image does not load completely and it covers only half of the card, for instance. And never finishes loading. We have not reverted it since it is not a major issue and just a few people complained about that.

I also want to understand if there's something else happening that is slowing things down (like, I've noticed that fetching gog images information is pretty slow, and it does that for the whole library, we could defer those requests to speed the gog library load)

This should be done only once since then we cache the image, so would solve only on a clean install.

I think a progress indication of what's happening also helps with the perceived speed, if it's just a spinner it feels like it might be stuck, but if we report updates like Loading GOG games... Fetching cover art (10/200) Fetching cover art (50/200) etc the user would know what's happening (and I think it can also help us understand where is the time going (a user could say hey, it takes super long in this specific step)

We could do that, we can create a general status for the app and send messages from the backend and show them on backend. that is a good idea.

thinking about that report of the library taking 2 minutes to load, do we know when is that time spent? because if it's in the backend when it's refreshing the libraries, using pagination won't fix that though, since we'll still need to process the whole library (it's not that we process the library in pages)

I think both legendary and gogdl needs some time to process big libraries.
That is not exactly an issue on the frontend, but after being loaded the interface will be laggy if there is a lot of cards.
You can test this right now, if you can try on the deck would be better, but add like 10 or 15 games to your favorites and then compare how Heroic behaves with the whole library and when showing the favorites only.

Then try again this branch and compare with or without the pagination. Is the same feel, and is faster and more responsive.

I'm closing this one since we merged the other one with the interception observer